Answer the question ADR 0004 said no documentation could - #41
Merged
Conversation
ADR 0004 shipped with one premise it could not check: whether a caller may
read the remaining chunks of a statement Genie executed on their behalf.
The link resolves to /api/2.0/sql/statements, which is not a Genie path,
and nothing published says whether the caller's identity carries there.
It does. A statement id taken from a completed Genie message returned HTTP
200 from both /api/2.0/sql/statements/{id} and .../result/chunks/0 using
the caller's own token, against the live Azure workspace.
The wire contract was checked the same way, on a deliberately chunked
statement run through the Statement Execution API so that no table had to
be created: total_chunk_count 2, chunk zero holding 41250 of 60000 rows, a
next_chunk_internal_link of /api/2.0/sql/statements/{id}/result/chunks/1 --
workspace-relative, the shape the client's host check accepts -- and
following it returning 18750 rows with no next_chunk_index. The two sum to
total_row_count exactly.
manifest.truncated was false on that result. That is the original defect's
premise, and it is now confirmed by observation rather than inferred from
the contract.
What is still not reached is Genie itself emitting a multi-chunk result.
The Agent used for verification has six rows and Genie bounds its own SQL,
so both halves are verified and their composition is not. Every document
that said "not exercised live" now says which half was and which was not,
because "verified" and "partly verified" are different claims and the
second one is the true one.
Also recorded: the service-principal token endpoint returns 401
invalid_client rather than 404 for deliberately wrong credentials, so the
URL, method, Basic auth and form parameters in the documented recipe are
right even though the exchange with real credentials has not been run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ADR 0004 shipped with one premise it could not check. It has now been checked against the live Azure
workspace, and it holds.
The unknown, and the answer
Question: may a caller read the remaining chunks of a statement Genie executed on their behalf?
The link resolves to
/api/2.0/sql/statements/…, which is not a Genie path, and nothing publishedsays whether the caller's identity carries there.
Answer: yes. A statement id taken from a completed Genie message, using the caller's own token:
GET /api/2.0/sql/statements/{genie-executed-id}SUCCEEDEDGET .../result/chunks/0The wire contract, checked the same way
A deliberately chunked statement —
SELECT id, repeat('x',120) FROM range(60000), run through theStatement Execution API so no table was created in the workspace:
manifest.total_chunk_count2manifest.truncatedon a merely-chunked resultfalse— the original defect's premise, now confirmed by observation rather than inferred41250of60000rowsnext_chunk_internal_link/api/2.0/sql/statements/{id}/result/chunks/1— workspace-relative, the shape the client's host validation acceptsrow_offset: 41250,row_count: 18750, nonext_chunk_index41250 + 18750 = 60000=total_row_countThat is the link shape, the chunk response shape, the loop's termination condition, and the row
arithmetic the truncation flag depends on — all four.
What is still not proven, and every doc now says so
Genie itself emitting a multi-chunk result. The Agent used for verification has a six-row table
and Genie bounds its own SQL, so both halves are verified while their composition is not. Every
document that previously said "not exercised live" now says which half was and which was not,
because "verified" and "partly verified" are different claims and the second is the true one.
The unreachable-chunk fallback stays — not because the permission answer was expected to be no, but
because a path returning rows to a user should not rest on an assumption nobody re-checks.
Also recorded
The service-principal token endpoint returns
401 invalid_client, not404, for deliberatelywrong credentials. The URL, method, HTTP Basic auth and form parameters in the documented recipe are
therefore correct, even though the exchange with real service-principal credentials has not been run.
Verification
Live suite 8/8 green against the workspace after the change. Full offline suite 224 tests green.
The CLI run end-to-end live returns a complete result correctly flagged
truncated: false. Allrelative links resolve. Documentation only — no source changes.